Exclude the Liquibase lock table and drop a no-op psql flag - #14

Two independent fixes to setup-postgres-preview-schema/job-template.yml, both found while migrating the test applications to cluster test02.

1. --set=SESSION_REPLICATION_ROLE=replica never did anything

--set defines a psql client variable, not a server parameter. The intent was clearly to disable triggers during the load, and that never happened.

Measured against a live PostgreSQL 18 database:

$ psql --set=SESSION_REPLICATION_ROLE=replica -tAc "show session_replication_role;"
origin

$ psql --set=SESSION_REPLICATION_ROLE=replica -tAc "\echo :SESSION_REPLICATION_ROLE"
replica

The server keeps origin. The value exists only as a client variable that nothing reads.

Why the fix is removal, not a real SET

The obvious repair would be the SQL SET session_replication_role = replica;. That cannot work here, because this job connects as the application role:

$ select name, context from pg_settings where name = 'session_replication_role';
 session_replication_role | superuser

$ set role aichner_projects; set session_replication_role = replica;
ERROR:  permission denied to set parameter "session_replication_role"

With --set=ON_ERROR_STOP=1 that error would abort every preview build. Granting the application role superuser to clone a schema is not worth it.

Why removing it is safe

A plain-format pg_dump writes the data first and adds the foreign keys at the end, so no trigger has to be suppressed during the COPY phase. In a real dump of one of our schemas:

 2856  COPY "main"."bank_account_balances" ...
13878  ADD CONSTRAINT "user_roles_role_id_fk" FOREIGN KEY ...

Roughly eleven thousand lines of data land before the first foreign key exists. The flag protected nothing, and its absence changes nothing.

2. The Liquibase lock row is cloned into every preview

databasechangeloglock holds runtime state, not history. Copying its row means a preview inherits whatever lock the base schema happened to hold. A base schema captured while Liquibase was mid-run hands the preview a lock that is already taken, and the preview application then blocks on startup.

--exclude-table-data keeps the table and drops its rows, so Liquibase writes a fresh lock row on first start. Verified against a live database:

lock table DDL kept      : 1
lock table DATA excluded : 0
changelog DATA kept      : 1

databasechangelog keeps its rows on purpose. That is the migration history, and the preview needs it so Liquibase applies no changeset twice.

Testing

Both commands were run against a live PostgreSQL 18 instance, on a real application schema. The job template still parses as a valid Kubernetes Job.

One thing this pull request does not fix

The sed that renames the base schema rewrites every occurrence of "${BASE_SCHEMA}", including references to objects that merely live in that schema. We hit this on Aichner: pg_trgm had been created without an explicit schema, so it landed in the application schema, and pg_dump emitted the trigram indexes as "main"."gin_trgm_ops". The rename turned that into "preview_1003"."gin_trgm_ops", which does not exist, and six preview jobs failed with:

ERROR: operator class "preview_1003.gin_trgm_ops" does not exist for access method "gin"

A purely textual rename cannot distinguish the two cases, so the durable fix belongs in the applications: never create an extension inside the application schema. Aichner now recreates pg_trgm in public. It may be worth stating that in the action's readme, so the next project does not repeat it.

🤖 Generated with Claude Code